Using this to reduce footgun opportunities since this is security-focused. On the other hand, it doesn't match how we handle app_settings, so I'm open to not going this route if folks have strong opinions about it.

I think the this need to be registered from the app the same way we have app.register_authorization

Agree that this doesn't belong to the settings class.

What I do think may cause confusion for end users is the AuthManager class which is defined in the oauth2_lib library:

class AuthManager:
    """Manages the authentication and authorization mechanisms for the application.

    This manager class orchestrates authentication and authorization, utilizing OpenID Connect (OIDC) and
    Open Policy Agent (OPA) respectively. It serves as a central hub for user authentication states and
    authorization policies. If defaults are insufficient, users can register alternatives or customize existing ones.
    ...."""

An instance of that class is created in the OrchestratorCore(FastAPI) class, and in downstream apps the authn/authz instances can be overridden like so:

    app.register_authentication(surf_authn)
    app.register_authorization(surf_authz)
    app.register_graphql_authorization(surf_graphql_authz)

The AuthManager's docstring suggests that it manages all authn/authz, but obviously this only holds for the API - the workflow authz is specifically for the Worker (which, in case of the threadpool executor, is running in the same process; but for the celery executor it will be separate).

I'm not suggesting we should make the Authorizers part of the AuthManager, maybe we can just name/document things well enough to avoid confusion. And perhaps tweak the AuthManager's docstring a little bit to say it's for the API.

auth manager isn't specifically for the API, I would have used it in our version for the authorize_callback if we could use an async function. I'm also not saying that they need to be included in the AuthManager within oauth2-lib, since its orchestrator specific.

the workflow authz is specifically for the Worker

Just to clarify - the API endpoints for creating and resuming processes do check these callbacks, along with a couple other REST and GraphQL endpoints. I'm not actually aware of the worker running these checks; by checking in the request handler, we can prevent the workflow from ever making it to the queue if the process shouldn't be queued/re-queued.

I originally considered adding OrchestratorCore.register_internal_authorization_callbacks(authorize_callback=None, retry_auth_callback=None). I decided against it at the time since the process of checking this info seems kinda independent of the app from the perspective of building orch-core. Something-something loose coupling. That said, I can see it being more intuitive for the end user to configure it as part of the application.

Should I add it to OrchestratorCore class, or just continue with the current approach while making it clear that AuthManager is a separate thing in the docs?

These could have gone into AppSettings, but it seemed like

1. it would be weird printing these out when settings are exposed
2. (more importantly) it would suggest to users that this can be set by environment variable

So I opted to separate them out. Feedback/direction appreciated.